Subject: Your note of 1jul93, "Directory Proposal"

From: "Mel Jones (Tie: 444-4363)" <[email-masked]>
Date: Wed, 28 Jul 93 18:53:18 EDT

Jeff:

Sorry for the delay in response, but I've been out of the office much
of the time since the last CIW.

To give some form to my comments, let me classify the portions of your
proposal into two categories:

  1. Alternative procedure for CPIC to access the directory
     a. a new CMINIT call instead of Set_Partner_ID

  2. New function
     a. Specification of the type of identifier provided by the program
     b. Specification of association/session addressing in the directory
        entry (e.g., inclusion of NSAP)

I'll address each of these portions in turn in the sections below.

-------------------------------------------------------
1. Alternative procedure for CPIC to access the directory
   a. a new CMINIT call instead of Set_Partner_ID, e.g., CMINITA

R0.  There's a part of me that has to say this is a good idea, since
this idea (actually, something called CMINIT2) was part of the
original directory proposal I came up with back in 1992.  There's
another part of me though, the part that went through the battles
that led to the current AD proposal, that recognizes there are
some problems with creating a second CMINIT call.  Some of these
arguments come down to a "beauty contest" of what seems better to
the person looking at it; some are real technical considerations.
Here's a little bit of the discussion (as best I can remember
from the distance):

R1.  There is a distinction between local and non-local calls, i.e.,
calls that block or don't block.  The current CMINIT is considered to be
strictly local and never hangs.  The proposed call, as you described it
(and as I originally described CMINIT2) would have to go off to the
directory and get the directory information.... which would mean that it
might block.  Making the call block (and it's your first call) means that
all of the stuff the non-blocking call allows you to set for queues,
etc., would have be specified on the call.  And what if the program
doesn't want to handle blocking (or, vice versa, a non-blocking call).
Etc. etc.  It gets very complicated and suddenly makes what was a simple
idea -- make this call, get a conv_ID -- start to seem complicated, and
duplicate function built in elsewhere.

R2.  The alternative path to paragraph R1 is to change the function
slightly -- you still let the program issue the call and specify it's DN
or whatever, you just don't actually access the directory at that point.
Now the problems with the blocking call are removed.  Unfortunately, this
now kludges up the other semantics of the call -- what if the
sym_dest_name was local and therefore the system could indeed resolve it
(as for side info)?  Do we now say that sometimes the destination_info
gets resolved and sometimes it doesn't happen until Allocate?
What about the difference between this call and the call that seems to
be the same name -- one actually gets data you can issue sets against,
but the other doesn't?  It quickly starts to get "messy" and no longer
"clean."

R3.  The step forward from this is to leave the call as a set, but make
it a call issued after the simple CMINIT.... which was how we got to
Set_Partner_ID.  The call is local, sets a value, but does not block.  It
fits in cleanly with the other Sets because they do the same sorts of
things -- establish information that gets used at Allocate.  This
approach also has the advantage that programs that don't want any
additional function besides a DN in side information don't have to do
anything to get use of the directory.

R4.  The "beauty contest" sorts of discussion that went on were
about having two calls by the same name for similar, but
different, function.  There's a distinct argument against
muddling up CPIC with "new versions" of existing calls unless you
*really* have to, and the sentiment was that creating a new
CMINIT would be just one more thing for the programmer to keep
track of.  "So I use CMINIT here, because I'm an old program, but
here I use CMINIT2, because I'm new...."

----------------------------------------------------------------------
  2. New function
     a. Specification of the type of identifier provided by the program

R5.  A new piece of function that you added in the CMINITA call proposal
was an identifier to point out what kind of name the program was passing,
e.g., was it an X.500 DN, a DCE DN, a local name, etc.  This seems
promising, and could easily be added to the existing Set_Partner_ID call,
but there are a couple of reasons why it probably shouldn't be added.

R6.  The first reason is that it's not needed.  I talked to the naming
experts I could get hold of and they confirmed my belief that you would
be able to tell what kind of name it was by looking at the name.  Thus,
for instance, DCE names look only like DCE names and are instantly
recognizable as such.  There are two forms of DCE names -- either one
that is fully X.500 compliant, or a "mixed form."  The mixed form is the
easiest to identify, because the latter portion of the name doesn't look
like X.500 at all.  If you're using a fully compliant X.500 name that's
for DCE, the latter portion will have equal signs and values, but a
special DCE-only name-type of "typeless" will be used.

R7.  Aside from that argument, this type of identifier is
limiting for the program.  The existing proposal allows the
program to specify an identifier -- it does not say *anything*
about what that identifier might be -- and promises that CPIC
will use it to try and find something in a distributed directory.
The type of directory used is determined by the implementation.
If the program initially runs on a CPIC implementation that
makes use of a roll-your-own directory, which is then later
updated to a DCE directory, and then later changed to make use of
a X.500 directory, the only thing that changes is the string,
which can be dynamically acquired.  If you force information on
the type of the underlying directory into the interface, you are
forcing more information that the program will have to specify
(and which will not be as accessible dynamically -- e.g., doing
a search based on PFID, determining the DN string, etc.).

----------------------------------------------------------------------
2. New function
   b. Specification of association/session addressing in the directory
      entry (e.g., inclusion of NSAP)

R8.  You've included the NSAP information as part of the
information that would be retrieved from the directory.  As was
discussed at the sig meeting after the June CIW, this is the
equivalent of putting the network-layer information required to
establish an SNA session into the interface.  This type of
information is not currently part of CPIC, and the inclusion of
the NSAP is also not part of the AP OSI proposal.  If we want to
include this information we need to first update those other
portions of the architecture so as not to get into the "you do it
here this way, but you do it there that way" trap I've already
discussed.  Right now, the OSI proposal places such info outside
the bounds of CPIC and the existing AD directory proposal does
likewise.

R9.  Personally, I'm not crazy about the notion of including this
information in the CPIC interface.  It's something that the application
shouldn't have to worry about, and doesn't today, but I understand your
concern about where the information will come from for OSI.  Right now,
we presume that session/association addressing information is available
from a lower layer (i.e., either the SNA or OSI protocol stack) and that
doesn't seem to be true for OSI.  The correct place for this question to
be answered is the OSI SIG -- if the OSI SIG decides to include NSAP etc.
as a Set call (with all the incumbent implications) then we can proceed
to see about getting it in the directory.

R10.  One thought to keep in mind on this point is whether it's wise to
do this from a performance view -- APPN, for instance, keeps it's control
point name (the moral equivalent of an NSAP, I think) in a different
directory for some very good reasons and would never consider using
something as slow as the DCE directory.  DCE's distributed directory
makes no promises of real-time updates for changes.

R11.  Another thought, which may come from my SNA-centric view of the
problem (and hence may not be as applicable for OSI), is that today a
system might have hundreds of programs that are available via a single
LU/CRM.  The same situation seems to be true for OSI -- multiple programs
are accessed via a single application-entity.  In SNA, partner programs
get to their partners by providing the LU name, not the session
addressing information for establishing a session with the LU.  If we
*were* to put the session addressing information for the LU into the
directory at each of those programs, there would be a huge duplication of
information (if the LU had 100 programs on it, all 100 program objects
would have the same information).  It gets worse when you consider
changing the information.  By just having the program use the LU name,
the duplication is limited and any change of session information is
hidden from the application.  It seems like this concern is also
applicable to OSI (which would mean you would want to store the NSAP
stuff somewhere else, in an object for the application-entity similar to
the way info for LUs is stored elsewhere), but I'm not OSI-knowledgeable
enough to be sure.
-----------------------------------------------------------------

You mentioned in your note that you'd like to see progress on the
directory work by the end of the summer, and I agree.  There hasn't been
much electronic traffic so far -- I assume a lot of people have been out
for summer vacations (it could never be that they find this stuff boring)
-- but maybe we can get things moving again.  Rich sent out meeting
minutes after the last SIG with some questions that still need to be
resolved.  I'll try and get a response to those out this week or early
next week and maybe we can see how the SIG sees about the existing
directory proposal.  If we can reach agreement, I'd be happy to ask for
interim AP approval in August.  In September we could focus on what needs
to be done to get CP by the end of the year.

I should be in the office more regularly -- no large disjoint blocks --
through the rest of the summer, so hopefully my response next time will
be more prompt.  Sorry about the delay this time.  I look forward to your
reply.

Regards,
Mel